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REMARKS 

Reconsideration and further examination of the application as amended are re- 
spectfully requested. All objections and rejections are respectfully traversed. 
Drawings 

In the Drawings, Fig. 1 was objected to because it does not include a "Prior Art" 
legend on it. Applicant attaches a replacement sheet for Fig. 1 to which the term "Prior 
Art" has been added. Accordingly, the objection to the drawings should be withdrawn. 

IDS 

On March 4, 2004, Applicant submitted an IDS enclosing a complete copy of the 
PCI-X specification standard for the Examiner's review. It was solely because of its 
large size that Applicant did not include a complete copy of the specification standard in 
the prior IDS (although Applicant did include a complete copy of the document's Table 
of Contents). Had the Examiner contacted counsel for the Applicant, counsel would have 
been happy to provide a complete copy of that document, or any other requested materi- 
als for that matter. No such telephone call was made, however. 

Claim Rejections 

Claims 1, 2, 4, 9 and 1 1 were rejected under 35 U.S.C. § 102(e) as being antici- 
pated by U.S. Patent No. 6,523,140 to Arndt et al. ("Arndt"). Claims 3, 10 and 13-15 
were rejected under 35 U.S.C. §103 as being obvious based on Arndt in view of PCI-X 
Addendum to the PCI Local Bus Specification, Revision 1.0 ("PCI-X Specification"). 
Claims 5-8 and 12 were objected to as depending from rejected base claims, but would be 
allowable if rewritten. 
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Claim 1, in relevant part, recites: 

"In a computer system ... an I/O bridge ... the I/O bridge comprising:" 

"a transaction engine . . ." 

"wherein the transaction engine:" 

"generates an attribute message that includes a tag field and a re- 
quester function number field," and 

"loads the requester function number field with a selected one of 
a plurality of values". 

That is, claim 1 positively recites that an "I/O bridge" loads one of a plurality of 
values into a requester function number field of an attribute message. 

Arndt fails to disclose such an I/O bridge. Applicant agrees that Arndt (as well as 
the PCI-X specification itself) discloses an attribute message 201 (Fig. 2) having a re- 
quester function number field 209. However, there is no disclosure by Arndt that his I/O 
bridge (111) loads the requester function number field (209) with any value whatsoever. 
Instead, Arndt discloses an I/O adapter (1 15 or 1 19), and not the I/O bridge (1 1 1), that 
loads values in the requester function number field (209). Specifically, Applicant directs 
the Examiner's attention to Col. 3, lines 40-43, which state as follows: 

Also, a requester function number segment 209 identifies the specific function 
number of the device requesting the transaction for devices that have multiple 
functions. 

That is, Arndt discloses only that an I/O adapter device (as opposed to an I/O bridge) may 

load a value in the requester function number field (209). This is confirmed by Arndt at 

Col. 3, lines 60-62, which state as follows: 

The frozen status of the PCI adapter is kept based on the PCI adapter's bus num- 
ber, device number and function number of the adapter . 
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In other words, Arndt makes clear that it is solely an I/O adapter (and not an I/O bridge) 

that loads a value into the requester function number field (209). 

This is consistent with the PCI-X specification standard as well. Applicant directs 

the Examiner's attention to Section 8.4.3.2.3 of the PCI-X specification standard, which 

states in part as follows: 

When the bridge creates the Split Completion, the bridge creates the Split Com- 
pletion address and Completer Attributes. It creates the Split Completion address 
from the original request, the same way a PCI-X completer would (see Section 
2.10.3). For the Completer Attributes, the bridge creates a Completer ID that 
partially describes the location of the conventional completer. If the conventional 
interface is the primary bus, the bridge supplies the bus number from the Primary 
Bus Number register in the conventional PCI Configuration Space header. If the 
conventional interface is the secondary bus, the bridge supplies the bus number 
from the Secondary Bus Number register. In both cases, the bridge sets the De- 
vice Number and Function Number fields to zero. 

In other words, as noted by the Applicant on p. 3, lines 7-8 of the Specification, I/O 

bridges are not multi-function devices, and therefore they do not enter any values (other 

than null or all zeros) in the requester function number field. 

Because Arndt fails to disclose an I/O bridge that loads the requester function 
number field of an attribute message with "a selected one of a plurality of values", the 
rejection based on Arndt should be withdrawn. See MPEP §2131 (The identical inven- 
tion must be shown in the cited reference in as complete detail as in the recited claim to 
support a rejection under §102). 

Similarly, independent claim 1 1 recites, in relevant part: 

"providing at least one queue having a plurality of entries . . and 

"associating each queue entry with a selected tag value and with one of a 
plurality of selected requester function number values". 
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Amdt fails to disclose an I/O bridge in which queue entries are associated with 
both tag values and "selected requester function number values." Instead, as noted 
above, the only use of requester function numbers disclosed by Arndt is by the I/O adapt- 
ers. Because Arndt provides no disclosure of associating queue entries with both tag val- 
ues and selected requester function numbers, the rejection of claim 1 1 should also be 
withdrawn. 

The rejected dependent claims are allowable because they depend from allowable 
base claims, and because they recite features neither disclosed nor suggested by the art of 
record. 

Claim 2, for example, recites in relevant part: 

"the transaction engine (of the I/O bridge) logically concatenates the tag field 
and the requester function number field ... to create a super tag value". 

Thus, claim 2 recites not only that the I/O bridge loads the requester function 
number field, but that the I/O bridge logically concatenates both the tag and the requester 
function numbers field into a single "super-tag" field. With these two fields logically 
concatenated together, the I/O bridge is able to support more tag values, thereby substan- 
tially increasing the number of split transactions that can be outstanding. Arndt provides 
no disclosure whatsoever of logically concatenating the tag and the requester function 
number fields into a new field. Instead, Arndt at all times treats the tag field 203 and the 
requester function number field 209 as two separate fields. 
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Applicant submits that the application is in condition for allowance and early fa- 
vorable action is respectfully requested. 

Respectfully submitted, 




Michael R. Reinemann 
Reg. No. 38,280 
(617)951-2500 



Send all correspondence to: 

IP Administration Legal Department, 
M/S35 

Hewlett-Packard Co. 

P.O. Box 272400 

Fort Collins, CO 80527-2400 
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